Information available to people becomes easily dispersed to different devices and information systems. Part of the information available may be located in files in fixed networks on servers or personal computers, for example. On the other hand, terminal devices of various cellular networks, laptop computers or palm computers contain information, files and programs that are important to the user. Maintaining them in a way that the latest created version of each piece of information, file or program is always the one currently in use is a challenging task.
The management of up-to-date information in prior art decentralized information networks is an important issue. This is particularly true in the management of information and software contained by various mobile devices. Such management of information and files is generally called Device Management. Device management has the following characteristic features, among others: It enables one terminal device or server to remote control at least one other device. It also enables a program or a part thereof in a terminal device to be complemented by new information or parts of a program, which are located in another device. In addition, the validity of the licenses, or rights of use, of software is also managed by it. Device management may also comprise matters related to the management of rights (Digital Right Management).
Open Mobile Alliance (OMA) has published specifications, which concern the updating and maintenance of software in mobile devices. Some possible ways of implementing data transfer and up-to-date file maintenance of mobile devices are described in the specifications OMA DM (Device Management) and OMA DS (Data Synchronization). These specifications describe the SyncML (Synchronization Markup Language) protocol and how it is utilized.
FIG. 1 is an exemplary signal chart of the prior art operation in a server-client device environment according to the OMA standard. The transfer of information and commands between the client device 11 and the device management server 12 requires a large amount of data transfer between them. In the description below, the device management server is often also referred to by the general name server. The performance of a procedure in a client device may require the execution of a number of separate commands in a certain order. The server 12 has the responsibility for the execution of the commands, the client device 11 only implements the commands it has received one by time and reports the result to the server which gave the commands. The commands have originally been specified in a user application not shown in FIG. 1, which delivers the commands to the device management server for execution.
The conversation between the device management server 12 and the client device 11 can be like the following, for example. The conversation is started by the client, which may be, for example, the physical user of the client device 11 or the server 12 or some application program being executed in the server or client device or some third device not shown in FIG. 1. In the example of FIG. 1, the exchange of commands and messages between the device management server 12 and the client device 11 is started by the client's action. After this, the server 12 sends the first command, Ref. 13, to the client device 11 for execution. After the execution, the client device 11 sends information, Ref. 14, of the result of the operation back to the server 12 which sent the command. If the first command has been executed, the server 12 sends the next command, Ref. 15, to the client device 11. The client device executes the second command it has received and sends information of the execution of the second command back to the server. In any case, the server 12 has to check every reply message it has received before it can proceed to the execution of the next command in the instruction sequence. The reply message received from the client device 11 may also result in that the server must make a decision on which command is sent to the client device next.
The server 12 can also report to the requester of the instruction sequence, the above mentioned client, after each command executed.
The exchange of messages lasts until the server 12 sends the last command belonging to the instruction sequence to the client device 11, Ref. 18. The execution information of the command is returned by a message 19 to the server 12. If the message indicates that the execution of the last command was also successful, the message exchange between the server 12 and the client device 11 is stopped.
A central problem in wireless data transfer is the limited data transfer channel used. The prior art conversation between the server 12 and the client device 11 for executing the instruction sequence consumes the limited data transfer resources of the wireless system unnecessarily.